home *** CD-ROM | disk | FTP | other *** search
/ Nebula 2 / Nebula Two.iso / SourceCode / MiscKit1.7.1 / MiscKitArchive.mbox / mbox / 000110_ets!mystic!kareth@uunet.UU.NET_Wed Feb 2 19:51 MST 1994.msg < prev    next >
Internet Message Format  |  1994-10-30  |  4KB

  1. Received: from yvax2.byu.edu by maine.et.byu.edu; Wed, 2 Feb 1994 19:51:41 -0700
  2. Return-Path: <ets!mystic!kareth@uunet.UU.NET>
  3. Received: from DIRECTORY-DAEMON by yvax.byu.edu (PMDF V4.3-3 #4169)
  4.  id <01H8F7BLOPS001A6C1@yvax.byu.edu>; Wed, 2 Feb 1994 19:51:29 MST
  5. Received: from alaska.et.byu.edu by yvax.byu.edu (PMDF V4.3-3 #4169)
  6.  id <01H8F7B8PJ5S8Y4ZH4@yvax.byu.edu>; Wed, 2 Feb 1994 19:51:13 MST
  7. Received: from yvax2.byu.edu by alaska.et.byu.edu; Wed,
  8.  2 Feb 1994 19:47:56 -0700
  9. Received: from DIRECTORY-DAEMON by yvax.byu.edu (PMDF V4.3-3 #4169)
  10.  id <01H8F76UTWDS01AC09@yvax.byu.edu>; Wed, 2 Feb 1994 19:47:41 MST
  11. Received: from relay1.UU.NET by yvax.byu.edu (PMDF V4.3-3 #4169)
  12.  id <01H8F76OFNUO8Y511R@yvax.byu.edu>; Wed, 2 Feb 1994 19:47:31 MST
  13. Received: from spool.uu.net (via LOCALHOST) by relay1.UU.NET with SMTP
  14.  (5.61/UUNET-internet-primary) id AAwbpb18784; Wed, 2 Feb 94 21:47:05 -0500
  15. Received: from ets.UUCP by uucp5.uu.net with UUCP/RMAIL (queueing-rmail)
  16.  id 214506.2800; Wed, 2 Feb 1994 21:45:06 EST
  17. Received: by mis00a (NX5.67d/NX3.0M) id AA01384; Wed, 2 Feb 94 21:35:45 -0500
  18. Received: by mystic (NX5.67d/NX3.0M) id AA19811; Wed, 2 Feb 94 21:23:09 -0500
  19. Received: by NeXT.Mailer (1.100)
  20. Received: by NeXT Mailer (1.100)
  21. Date: Wed, 02 Feb 1994 21:23:09 -0500
  22. From: Doug McClure <ets!mystic!kareth@uunet.UU.NET>
  23. Subject: Re: More object ideas
  24. To: misckit@byu.edu
  25. Message-Id: <9402030223.AA19811@mystic>
  26. Content-Transfer-Encoding: 7BIT
  27. Status: RO
  28.  
  29.  
  30. As to my ideas of a File class and a Unix class.
  31.  
  32. My original idea behind having the Unix class being a subclass of Process (or SubProcess as the case may be) was such that commands like 'cp, mv, ln, etc' are processes and should be treated is such.  Then I could have the commands run in the foreground/background, whatever.  The Process class would handle it.
  33.  
  34. The idea behind the File class was that it would be a generic class deaing with a file descriptor, not a file.  The file descriptor could then be hooked up to anything the class could handle.  For the File class, this could indeed be a file, but it also might be stdout or stderr.  I didn't mean to imply that it dealt with files but with input/output which is done to a file descriptor.
  35.  
  36. This division of the two, to me at least, makes much more sense considering what the two classes would be responsible for doing.
  37.  
  38.     The trick here is that with OpenStep up and coming,
  39.     we will have to be very careful that only certain
  40.     subclasses or categories introduce OS dependencies.
  41.  
  42. That's one of the reason's why I thought this class would be great.  Even if OS dependencies are introduced, they can be handled in the class code which would free us developers up from having to do all kinds of fancy tricks to handle OS dependencies in our code.  The methods would perform the same on whatever platform.
  43.  
  44.     Oh, and I _really_ think that it
  45.     would be handy to have a subclass of the file object
  46.     to deal with directories.  That would sure make
  47.     surfing through a filesystem a cakewalk!
  48.  
  49. Yeah, that would be pretty cool.  But I'm not sure if a class for looking through directories would fit under a class for I/O on a file descriptor.  Maybe more thought is needed on exactly how to divide these types of classes up.  I suppose a directory would just be a file descriptor, with some specialized commands to search through the I/O stream.
  50.  
  51.     As to the logging, yes, both a "priority level"
  52.     _and_ a mask would be useful.  I'm more in favor
  53.     of a mask, though.
  54.  
  55. The mask idea is great, but exactly how portable would that be?
  56.  
  57.     Well, who's our file handling guru gonna be, then?
  58.  
  59. I'd love to do it, but I doubt I know enough about all the different things that can be done to file descriptors.  I'd definitely like to help if any input is needed.
  60.  
  61.     (PS:  more objects:  Sean Luke's sound meters and other
  62.     stuff is almost ready.  Looking real nice.  He's even
  63.     got a little example app that sits there and lights up
  64.     whenever there's noise in the room.  Rather unnerving.)
  65.    
  66. Hey cool!  A prototype alarm system!
  67.  
  68. -dougm
  69. dougm@ets.com
  70.